Forum PHP.pl

mail też jest słabym pomysłem - jest pełno serwisów, które oferują tworzenie czasowych maili

Można zrobić listę dozwolonych maili.

No ale również to nie jest żaden problem poświęcić 5min aby stworzyć konto pocztowe np w wp.pl a nawet 10min na dwa takie konta itd.
A to wielka szkoda sprawdzanie nawet randomowego id poprzez cookies też można luźno ominąć poprzez wyczyszczenie ciasteczek:/

Pomyślałem również aby IP było sprawdzane jak i aktualizowane przy każdym logowaniu oraz wylogowaniu no i rejestracji.
Banalne rozwiązanie ale chyba lepszego nie znajdę a zawsze to jakiś tam sposób na chociaż drobne zabezpieczenie.

Chociaż sprawa się wymyka z pod kontroli jeśli to użytkownik znajduje się w sieci i pozostałe osoby w jego sieci już się nie zarejestrują z nowym kontem.

Ten post edytował Soulast 12.07.2010, 09:57:02

Soulast,

http://forum.php.pl/index.php?showtopic=141712&hl=

Zapraszam do mojego topicu, jest troche wiecej na temat 1uzytkownik - 1konto, ale niestety idealnego rozwiazania chyba nie ma :/

Hey,
mam pytanie jak najlepiej zabezpieczyć upload/server/download aby user mógł uploadować dowolne pliki nawet wirus.php , aby każdy mógł pobrać ale aby się nie mogły wykonać na servie ?

Servie? A zresztą nieważne.

Normalnie, wrzucasz je na serwer, pozostawiasz jedynie prawa do odczytu/zapisu dla użytkownika serwera HTTP, dla całej reszty zabraniasz wszystkiego. Pliki PHP to zwykłe pliki tekstowe - więc nie da się ich wykonać.

zerknij na http://www.beldzio.com/bezpieczny-upload-plikow

Bełdzio czytałem kiedyś, tylko zastanawiam się czy nadawanie losowych nazw + regułka dla folderu z plikami :
order deny,allow
deny from all
zapewnią mi w 100% bezpieczeństwo że ktoś czegoś nie wykona.
Bo sprawdzenia mime nie będzie, user będzie mógł wsadzić co mu się podoba.

Crozin dobrze pisze, zablokować wykonywanie plików.

jak zablokujesz dostęp do folderu to raczej średnio będzie z możliwością dostęu / wykonania pliku, który się w nim znajduje (IMG:style_emoticons/default/smile.gif)

regułka w mod_rewrite żeby wszystko przekierowywało na (np.) index.php a w nim readfile() (+ inne śmiecie do wyświetlania mime)

tyle, że samym readfile też można sporo namieszać (IMG:style_emoticons/default/smile.gif) tak więc też trzeba zrobić to z głową

Ten post edytował bełdzio 12.10.2010, 10:24:28

Owszem, może ale wystarczy dodać sprawdzanie nazwy pliku/katalogu i po problemie. Lub też mieć nazwy plików w bazie a w tedy odwoływać się do plików poprzez id.
i najważniejsze, katalog z plikami nie dostępny z zewnątrz.

przy złej implementacji "najwyżej" ktoś pobierze spobie konfigurację do bazy danych i parę innych plików/danych (IMG:style_emoticons/default/smile.gif)

Hey,
co to za rodzaj ataku że komuś się dolepia do strony:
/strona.php?page=php://input
Z logów mi wynika że od pewnego czasu ktoś mnie ciągle tym częstuje ...

zobacz sobie raw post data, php://input zawiera niesparsowane dane przesłane na serwer poprzez post

hey,
powiedzcie jak się zabezpieczacie przed atakami na usera typu [img=mojastrona.pl/ct/act?delete=id_czegos_danego_usera ?
Niby powinno wystarczyć danie w bootstrapie takiego kodu:

[PHP] pobierz, plaintext 
if($_GET){
        //czy jest ref ?
	if(isset($_GET['delete']) && !isset($_SERVER['HTTP_REFERER'])){
		exit;
	}
 
        //czy ref to nasza strona ?
	if(isset($_GET['delete'])){
            $host = parse_url($_SERVER['HTTP_REFERER']);
            $host = $host['host'];
            $local = $_SERVER['HTTP_HOST'];
            if($host !== $local ){
		exit;
            }
	}
}
[PHP] pobierz, plaintext 

Ale czy to aby na 100% zapewni nam bezpieczeństwo?
Co jeszcze dajecie aby czuć się bezpieczniej?

A co jeśli wyłączę sobie wysyłanie nagłówka REFERER?

1. Akcje dodaj, usuń, edytuj, przenieś itp. powinny być wykonywane metodą POST.
2. Niezależnie od metody używaj jednorazowego, unikalnego tokenu.
3. CSRF.

1) Wysłanie postem
2) Wymagany dodatkowy losowy klucz w parametrze $_GET (generowany na stronie poprzedniej i np zapisywany w sesji)
3) Przy bardzo wrażliwych danych ponowne zalogowanie
4) To z refererem też jest niegłupie

1. Wysyłaj dane postem (słabe zabezpieczenie).
2. Operacje mogące spowodować jakiekolwiek szkody - weryfikacja przy pomocy tokena.
3. Operacje mogące spowodować duże szkody - wymaganie podania hasła.

A czy nie dałoby radę zabezpieczyć plików przed potencjalnym hax0rem w .htaccess? coś typu Disallow from all i dać sobie dostęp tylko do plików na IP które mogą zaszkodzić stronie (IMG:style_emoticons/default/tongue.gif) w sumie zabezpieczaniu jestem na początkowym stanie, ale ostatnio sprawdzałem u kumpla czy może wbić w dany plik i wyskoczyło mu że nie ma dostępu :]. Fakt że hax0r będzie szukał głębiej, nie mniej jednak i tak to jest jakieś zabezpieczenie już.